前言

在上一篇試著分享了最通用的 Prompt 優化方式，但要知道 LLM 還能更強，就像替身能力能透過箭再進化是相同的意思，等等... 你那什麼表情？... 不想再看這系列文了？....

那廢話不多說開始進入正題！

關於 MCP 的概念

MCP 完整名稱是 Model Context Protocol ，它們分別代表

• Model（模型）：指的就是各個大語言模型（ Claude, Gemini, GPT )
• Context（上下文）：提供給模型的資料
• Protocol（協定）：一個通用的標準

你可以簡單了解 MCP 就是為了 統一規範應用程式提供給 LLM 的資料格式的開放協議，官方文件明確的以 USB-C 接頭作為比喻， MCP 的誕生就是為了解決不同應用串接規格不同而誕生。

USB-C 是一種通用硬體介面規格，在它出現以前，各品牌的硬體規格都不同，這導致消費者攜帶麻煩，經典的案例：安卓手機 (Micro-USB) 跟蘋果手機 (Lightning) 充電線無法共用。

下面的程式碼，同樣是前端的你肯定不陌生，畢竟串接 API 這件事非常基本也重要

axios.get(url,{config}).then(()=>{
	//...
})

那你還記得 API 全名嗎？它全名是 Application Programming Interface 這樣理解起來，我認為它也算是一種介面規範：

• 規範應用間的溝通介面（像是 header , session 定義)
• 規範資料格式

先說我相信 MCP 一定有更好的優勢，但還是來探索一下兩者的差異吧。

MCP vs 傳統 API 差異在哪？

假設今天你在一個 AI 聊天平台輸入

請幫我根據 figma 設計稿進行切版

如果今天背後是採取 API 方式，背後會經過

送出請求   
⇒ 1.DNS 解析  
⇒ 2.TCP 三次交握  
⇒ 3.TLS 握手  
⇒ 4.發送 HTTP 請求(帶Token/金鑰）   
⇒ 5.Figma 伺服器（驗證、商業邏輯、查 DB/外部 API）  
⇒ 6.回傳 HTTP 回應（JSON/串流）  
⇒ 7.前端把組裝好的 JSON/轉換後的資訊傳給 LLM（可能要壓縮或摘要，不然容易超過上下文限制）
⇒ LLM 處理後回傳

如果是使用 MCP ，中間則會

送出連線請求（MCP Client）  
⇒ 1.DNS 解析  
⇒ 2.TCP 三次交握  
⇒ 3.TLS/HTTPS/WS 協商  
⇒ 4.連到 MCP Server 
⇒ 5.檢視可用方法（tools 列表)
⇒ 6.Schema/參數描述（JSON-RPC 方法）  
⇒ 7.(可選）使用者授權/Token 交換
⇒ 8.建立 MCP 會話
⇒ 9.LLM 處理後回傳

到目前為止，兩者相同的部分是 都會需要建立連線，不同部分則是 回傳資料的處理時機以及 Token 存放位置，可以理解若是採用傳統 API 方式，前端會需要額外手動處理回傳的內容且需注意上下文限制。

而 MCP 設計上充分考量 AI 使用情境，內建自我描述能力，允許伺服器宣告其可提供的資源與操作，模型代理可以動態探索可用工具清單，另一點是 MCP 在處理回傳內容上能返回更加結構化上下文供模型直接使用。

接著我們進行第二次的呼叫

請再幫我修改間距

API

送出請求   
⇒ 1.DNS 解析  
⇒ 2.TCP 三次交握  
⇒ 3.TLS 握手  
⇒ 4.發送 HTTP 請求(帶Token/金鑰）   
⇒ 5.Figma 伺服器（驗證、商業邏輯、查 DB/外部 API）  
⇒ 6.回傳 HTTP 回應（JSON/串流）  
⇒ 7.前端把組裝好的 JSON/轉換後的資訊傳給 LLM（可能要壓縮或摘要，不然容易超過上下文限制）
⇒ LLM 處理後回傳

MCP

⇒ 4.連到 MCP Server 
⇒ 5.檢視可用方法（tools 列表)
⇒ 6.Schema/參數描述（JSON-RPC 方法）  
⇒ 7.(可選）使用者授權/Token 交換
⇒ 8.建立 MCP 會話
⇒ 9.LLM 處理後回傳

差別更明顯了，傳統的API 通常缺乏長連線的概念，每次請求之間彼此獨立，所以都要重新跑連線流程，但是 MCP 支援即時雙向互動，在一個持續會話中可進行多輪資料查詢和工具調用，中間都不需要重新連線。

以上述範例來說，兩者很明確的具有以下的差別：

• 使用體驗：傳統 API 缺乏長連線的概念，每次對話都要重新連線請求，使用者體驗較差
• 安全性與管理：假設今天有多個不同服務API，每個服務的安全驗證都不同，管理上比 MCP 麻煩，MCP 強調統一的存取控制，在協定層面提供驗證與權限管理框架。
• 上下文品質：傳統 API 將資料轉換為上下文需要手工處理，內容處理的細緻度也不如 MCP 處理，這樣一來就會影響 LLM 回覆品質

還有其他的差異，以下先附上其他人整理的表格圖

圖片來源：https://miro.medium.com/v2/resize:fit:1400/format:webp/1*_aj32f0DfHHhKCO5-sbaCA.png

小結

本來覺得 MCP 可以大概寫一下就好，但是實際寫下去發現很多細節可以探索其實挺有趣的，所以決定明天的規劃是進一步探索它背後的運作原理以風險。

那麼，明天見。

-- to be continued --

參考

What is the Model Context Protocol (MCP)?
什麼是 MCP?
MCP（模型上下文協定）是什麼？技術原理解析
[ 技術名詞介紹 ] AI 的 USB-C 接頭：深入淺出模型上下文協定 (MCP)